Not sure if it is a good idea to initialize a logger from within a library... like tests should perhaps create their own logger? Like I would hate if this somehow interferes with my env when I load this lib.

Actually, this like totally freaks me out. + .gitignore won't help here as logs will be created inside the folder of an application using this library. I suggest either removing this completely or making logging optional via some configuration flag. A local database or configuration files is understandable, but a library/crate creating its own logs without any external control over it is a rather bad etiquette.

I would perhaps suggest accepting Option<&Path> that contains a log file name or if None, logging is skipped across the entire library.

Good point, I had a custom logging mechanism before but was told that this is bad practice and that RUST_LOG env should be used.

Serializable trait and impl look useless here as you can invoke bincode::serialize() directly on PriceData.

Consider adding Debug to derive so that you can use println!("{:#?}", price_data); in tests to get formatted output.

If this behavior is intended, then it is cleaner to use:

if let Err(err) = crypto_prices.tree.insert( ... ) {
   log::error!("...");
}

Perhaps passing by reference here could be more efficient?

If you pass configuration by reference, you might not need to clone? (AFAICS)

I personally don't really like to create implementations in lib.rs, but there are no written rules about this. Just if the project grows it can become a bit cluttered. I would consider creating config.rs and error.rs containing appropriate structs.

Also, I would say that it is more common for crates to export Error as opposed to DatabaseError as any importer can import use xxx::Error as DatabaseError.

I think you could perhaps use more idiomatic rust here:

fetch_price_for_contract(crypto_prices.clone().configuration, address)
  .await
  .and_then(|data| crypto_prices.tree.insert(...))
  .or_else(|err| err);

... or along these lines ...

Paths are typically handled via std::path::Path or a generic can also be useful here such as:

pub fn new<P : AsRef<Path>>( ..., sled_path: P, ...) {
   let db = sled::open(sled_path.as_ref()).unwrap();
   ...
}

Change CryptoPrices to Self

Perhaps it would make sense to change new() -> Self to try_new() -> Result<Self> and handle sled opening as let db = sled::open(sled_path)?; to cascade the error to the invocator?